Columbia Kermit/kermit.zip/newsgroups/misc.19941221-19950208/[e-mail]_Sat Dec 31 14:22:38 1994.msg

Internet Message Format | 2020-01-01 | 6KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA22473
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Sat, 31 Dec 1994 23:03:00 -0500
Received: by apakabar.cc.columbia.edu id AA23691
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Sat, 31 Dec 1994 23:02:59 -0500
Path: news.columbia.edu!panix!bloom-beacon.mit.edu!gatech!swrinde!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: [e-mail] (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: File transfers are too slow
Message-Id: <[e-mail]>
Date: 31 Dec 94 20:22:38 MDT
References: <3e51i2$[e-mail]>
Organization: Utah State University
Lines: 86
Apparently-To: [e-mail]

In article <3e51i2$[e-mail]>, [e-mail] (Jon M. Taylor) writes:
>
>     I know this is a FAQ, but I've already read the FAQ, all the help
> files, and played around a lot and I still have speed problems. Soooo....
>
>     Situation:  I am connecting from my home computer (486/33,
> v.32bis modem, latest beta DOS kermit 3.14) to the university computer
> (HP 9000/715, OS 9.x)  Via a Xyplex terminal server that is set to
> swallow XON/XOFF chars and cannot |-< be changed (idiot admins...).
> This, BTW, is why I *HAVE* to use Kermit.  I used to be able to change
> the XON/XOFF passthru, but I now cannot and as a result Zmodem just
> refuses to work at all.  Yaaay Kermit!  I switched out of desperation,
> but I am now a convert.
>     Anyway, I have compiled 5A(190) for HPUX, and it seems to work
> correctly (so far, anyway).  I get maximal throughput with packet length
> set to 2000 (more works OK, but doesn't seem to make a difference in
> throughtput), all the control characters from the FAST macro enabled, and
> windows set to 1.  My modem DTR is locked at 38400, compression and error
> correction enabled, and it connects to the Xyplex at 14.4k with
> compression and EC on.  With this setup, I get ~1150 CPS.
>     Here's the rub:  Things start breaking down with any other window
> setting than 1.  The symptoms are: About 5 or so (it varies a bit) blocks
> will transfer OK, during which the window setting stays at "1 of
> [maxwin]".  Then, the transfer will halt temporarily (but no retries
> occur), and then the next block will transfer at half the original cps and
> one more window.  Halt, transfer one more block at half the cps and one
> more window, and repeat until max windows are reached, at which point the
> number of windows returns to 1, the cps maxes out again, and we repeat the
> whole cycle.  With max windows set to 2, this cycles often, with 32 the
> cps drops to about 16(!!!) at about 10 windows and stays there until 32,
> when it cycles back to one again.
>
>     Some other misc. info:
>
> - stty shows 9600; I changed it to 19200 with indeterminate results.  The
> Xyplex DTR is set to 19200, I think.
>
> - c-kermit on the HP initially uses XON/XOFF.  I'm not sure whether to
> change this or not - would the Xyplex need it?  I *think* the xyplex uses
> XON/XOFF to talk to the HP and DSR/DTR to talk to my modem....
>
> - I use doublespace with a large disk cache.
>
>     Also, while I'm here, I want to say thanks to Joe Doupnik (I used
> to go to school at USU!) and Frank da Cruz for MS-Kermit and C-Kermit.
> NOTHING but Kermit will work over this damn Xyplex, and I'm really glad
> it's out there.  A couple suggestions:  Have the percentage efficiency and
> CPS rating be updated in realtime during the transfer, like most other
> common protocols do.  I currently have to stop the transfer to see these.
> Given that most folx need to play with the settings, this would be a nice
> touch.  Also, since you seem to be aiming for maximum configurablility,
> how about an option to completely turn off ALL error checking in the
> protocol (like Ymodem-G)?  It would add another little speed boost to
> those who have EC modems.
>     I'll live with ~1150 cps if I *have* to, but I see no reason why
> I couldn't come close to 1600, *if* Windows worked.  Any help is appreciated.
>
>     -Jon
-----------------
    You have two knobs to twist: "how much/packet length" and "time/window
slots". Window slots cover up for delays of transmission and analysis time,
by allowing the transmitter to continue sending before the receiver's ACKs
arrive. Simply lengthening packets tries to cover up trasmission delays and
analysis time by having fewer intervals between packets, and of course fewer
header bytes to be exchanged too. But longer packets mean real buffering
problems along the route, as you seem to have discovered.
    I suggest backing down some. Use smaller packets and at least two
window slots. The product can be a few K bytes or less, depending on your
particular site. Then that nasty flow control problem needs some probing,
if possible.

    Your suggestions. Per packet window decorations cost performance,
and "efficiency" figures apply only to serial port comms (and not very
well to them these days with higher speeds on the DTE-DCE path than on the
telco wires). We won't even consider turning off error detection: not only
are modems not always error correcting, and never perfectly so even then,
but there are a host of other causes of trouble, and you are assuming that
checking is a serious performance penalty. Y-modem is hardly a protocol at
all: it's a send & pray scheme.
    Speaking in harsh terms it is my feeling that secure file transfers
are more important by far than either visual entertainment or games about the
last bit/second; after all, within reason what is being transfered ought to be
more important than the act of transferral.

    I hope you can sort out that horrid Xyplex terminal server problem.
    Joe D.